BROK et al. 

AppL No. 09/450,941 

April 4, 2005 

REMARKS 

Reconsideration and allowance of the subject application are respectfully requested. 

Claims 1-35 stand rejected under 35 U.S.C. 103 as being unpatentable in view of the 
Winzip helpfile document. This rejection is respectfully traversed. 

There are several known techniques for storing a large number of documents in a 
database. A single document in the database may contain references to other documents, 
graphics files, and/or sound files of the same database or even to a separate database. An 
example of such a document is an HTML document widely used in the IntemetAVorld Wide 
Web (WWW) environment. Typically, a database of HTML documents is stored on a web 
server connected to the World Wide Web. A user can browse documents stored in the database 
at the web server using a web browser. Typically, the web server receives a uniform resource 
locator (URL) request from the web browser, decodes URL, handles the document files, and 
sends the requested files to the web browser. It is also possible to browse documents locally in a 
local file system in a stand-alone data processing device that is not connected to the World Wide 
Web. In this case, the document address corresponding to a local file path is given to the local 
file system which then retrieves the file for the browser. 

These conventional arrangements are problematic in a situation where a document 
database has been configured so that a set of multiple documents is stored as a single file . 
Typically, the browser can only access separate documents located at a given URL address. But 
in a single file database structure, those documents stored in the single file can not be accessed in 
this traditional fashion. 

Nevertheless, there is a significant advantage to structuring a database that includes 
thousands of individual documents by storing them as a single file. A single file can be managed 
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much more easily than thousands of separate files, some of which may be of different file types. 
Moreover, the single file is more readily assigned a product identity and a version identifier, 
facilitating guarantee of the quality of the information contained in the database through proper 
version handling. 

Each of the multiple documents in a single file database typically contains links to other 
documents in that database. This creates a problem if it is desired to make the database 
transferable to different locations. In other w^ords, the document links must be defined and 
handled so that a location-independent database can be achieved. Moreover, it would 
advantageous if the single file database could be defined so that the same database management 
could be used in a network context (the database could be copied to any network server), and a 
local file system in a stand-alone data processor (the database could be copied to any file path in 
the file system). 

^AWLJwiit All V \^iinv>rii o^^ivwo tilwow pA \j L/i^iiio cliiu U-VIIA^ V Wi3 tiiC/OV^ uwoil ciuiv./ w uj wi./ 11 V ^ i3 uy 

storing the multiple documents in a single file database using a specialized protocol. A non- 
limiting example of this single file database protocol is set forth in the detailed description 
starting on page 11 and is referred to as 'edw'. But the browser does not understand a 
specialized, single file database syntax. Accordingly, the references in the documents (e.g., 
URL's) must be transformed before a document in the database can be provided to the browser 
for display. This is true for a network server application and for a stand-alone data processor 
application. 

The Winzip helpfile document lacks multiple features recited in the independent claims. 
It allows multiple files to be compressed and stored as a single archive file called a zip file. 
Those files can also be extracted and decompressed using an unzip operation. The step by step 
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example the Examiner relies on in pages 6-8 describes creating two simple text document files 
one.txt and two.txt, saving them to a directory c:\foo, and creating a zip file c:\foo/test.zip to 
archive those files. Winzip allows viewing the files simply by double clicking on the filename or 
by performing an extract operation. 

Regarding claims 1 and 12, the Examiner is presumably construing the zip file as the 
claimed database and the zip file c:\foo/test.zip as the claimed single file. But how can a zip file 
be construed as a database? Although it is possible that a zip file may be retrieved from a 
database, that is not described in the Winzip helpfile document. But if it were, then there would 
not be any teaching of retrieving the one document (not a zip file) from the database in response 
to a request for that document (not for a zip file). 

The Examiner also fails to point out where the Winzip helpfile document describes that a 
browser retrieves the document. But assuming there is some program that can be construed as a 
browser, Applicants find no teaching of any one of the tv/o document files one.txt and tv/o.txt 
stored in the zip file "containing links" to other files or any teaching of "scanning the retrieved 
document to identify said links." Where in the text of the one.txt and two.txt files, i.e., "this is 
the first file" and "this is the second file" (see pags 6 and 7), are there links to other documents? 
Where does the Winzip helpfile document describe scanning either document for links? 

To contend that such links "could be" inserted into the two documents and that the two 
documents "could be" scanned for those links is impermissible hindsight. The standard for 
obviousness is not feasibilitv of doing something. There must be some express motivation in the 
prior art that suggests the desirability of doing it. See Winner Int'l Royalty Corp. v. Wang, 202 
F.3d 1340, 1349 (Fed. Cir. 2000). 



- 11 - 



BROK et al. 

Appl. No. 09/450,941 

April 4, 2005 

The Examiner's contentions regarding "transforming the links into a format which is 
recognizable by the document browser" are untenable. First, NOTEPAD is not a browser. 
Second, NOTEPAD simply opens and provides immediate access to the text. There is no link 
transformation needed and none is performed. Indeed, there are no links to be transformed in the 
two documents described in the Winzip helpfile document. And Winzip merely decompresses 
the document file, but that no one skilled in the art would view decompression of a file as 
transforming document links into a format recognizable by a browser. Again, the the Winzip 
helpfile document does not even describe a browser; nor does it describe NOTEPAD as looking 
for or needing to recognize any document links. 

The Examiner also fails to identify where the Winzip helpfile document describes the 
"transmitting" step of claiml. The rejections of claim 3, 4, 13 and 20 are improper for similar 
reasons. In addition, there is no teaching in the Winzip helpfile document of "dynamically 
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form said browser is capable of understanding" (quoted form claim 3). 

There is certainly no recognition in the Winzip helpfile document of the problems of 
using such a single file database when documents are retrieved by web browsers. The Federal 
Circuit requires consideration of the problem confronted by the inventor in determining whether 
it would have been obvious to combine references in order to solve that problem. Northern 
Telecom, Inc. v. Datapoint Corp,, 908 F.2d 931, 935 (Fed. Cir. 1990). Indeed, the Examiner 
must show reasons why one of ordinary skill in the art, confronted with the same problem as the 
inventor and with no knowledge of the claimed invention, would select the elements from the 
cited prior art references for combination in the manner claimed. See In re Roujfet, 149 F.3d 
1350, 1357 (Fed. Cir. 1998). 
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The Examiner fails to show that the Winzip helpfile document recognizes or confronts 
the same problem as the instant inventors. Absent that recognition, it is clear that the Examiner's 
attempted combination lacks the requisite motivation. The Roujfet Court warned against 
"rejecting patents solely by finding prior art corollaries for the claimed elements" because that 
would "permit an Examiner to use the claimed invention itself as a blueprint for piecing together 
elements in the prior art." In re Roujfet, 149 F.3d at 1357. That approach was found by the 
Federal Circuit to be "an illogical and inappropriate process by which to determine 
patentability." Sensonics v. Aerosonic Corp., 85 F.3d 1566, 1570 (Fed. Cir. 1996). 

The application is now in condition for allowance. An early notice to that effect is 
earnestly solicited. 
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